(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ordlogo.gif)
0
0
By David C. Moss
As we've discussed over the past few months, logical models are the most effective way to identify, analyze, and record the areas of your organization that would benefit most from automation. Once you've created a complete logical model, you can use the information you've entered in Designer/2000 to design and generate Developer/2000 components, such as Forms, Reports, Graphics, and Procedures. Let's quickly review what we've covered.
In our February article, we used the Process Modeller to create and refine a picture of how things work at your organization by break-ing that work down into bite-size chunks called processes. In our March article, we explained how function hierarchy modeling helps you and your users reach agreement on the scope of your application. And in our April article, we explained how you and your users can employ Entity-Relationship modeling to create a logical data model of your organization's information needs.
The remaining tool in Designer/2000 for modeling the logical part of your application is the Matrix Diagrammer, which we'll examine in this article. Matrix modeling is the most effective means for checking the quality of your logical model. And the Matrix Diagrammer is an excellent tool for cross-checking your process, function hierarchy, and E-R models for completeness and consistency.
By the way, it's important to understand that matrix modeling doesn't always come last in the logical modeling process. Although we've discussed process, function hierarchy, and E-R modeling in separate articles, in the real world you'll collect and model much of this information at the same time. This is true for matrix modeling as well.
In this article, we'll examine the details of cross-checking using matrix models, and then we'll discuss using the Matrix Diagrammer in Designer/2000. Finally, we'll show how you can determine when your matrix modeling, and therefore your logical model, is complete.
A matrix is a two-dimensional grid showing how one element is affected by another. For example, to perform the Maintain Customer Accounts function, you need information from the Customer entity. We used the Matrix Diagrammer to create the matrix shown in Figure A.
Although there are many possible matrix combinations--Function to Business Objective, Event to Function, and Function to Attribute--the most commonly used matrix is Function to Entity. We'll focus on this matrix for the remainder of the article.
Once you've identified and reached agreement with your users on most of your functions and entities, you still need to complete another step. That step involves examining functions and entities to make sure all of your elementary functions use at least one entity. When a function uses an entity, it does so in one or more of four ways: Create, Retrieve, Update, or Delete--better known as CRUD.
Designer/2000 comes with some nifty tools that allow you to automate part of the process of matching entities to functions. The tool is called Generate Candidate Function/Entity Matrix. However, there's a bit of a catch. To make it work well, you need to make sure that all of your elementary functions refer to entities, or synonyms of entities, within your E-R diagram. The program can then search the text of each elementary function to look for entity names and create a simple matrix that you can refine.
For example, in our Frick and Frack application, the program will recognize that the Maintain Customer Accounts function utilizes the Customer and Account entities. But it wouldn't recognize a match if Maintain Customer Accounts was instead called Maintain Applications--unless of course you had an Applications entity!
So, if you've followed the rules, you can start the cross-checking process with a good first guess at your Function to Entity matrix. Now you need to look at each elementary function and make sure it has all the necessary entities and attributes to do its job, down to the CRUD for each function. And in terms of cross-checking, if you have elementary functions that can't use any of the entities in your diagram--and there are some great reports in Designer/2000 to tell you just that--it can mean one of three things: You have one or more missing entities; you may not understand the function as well as you thought; or maybe the function isn't necessary for your application. If you have any of these problems, you need to go back to your users.
When you've completed your Function to Entity matrix analysis, you need to look at things from the opposite direction: Are there any entities out there that aren't being used by a function? Again, there is a great report in Designer/2000 that can give you this information in a snap. You can find it by drilling down through Repository Reports to Data Model Reports to the Entities Not Used by Functions report. After you've run this report, you need to determine whether there are missing functions, you don't understand the contents of those entities well enough, or your application simply doesn't need the entities. You need to discuss this with your users to make sure you arrive at the right decision.
You could probably perform all the necessary matrix modeling work manually for a small project, say, a couple dozen functions and a handful of entities, but there's an easier way. Besides, in a large project with 1,000 functions and 225 entities, it's simply impossible to do this important work manually. That's where the Matrix Diagrammer in Designer/2000 comes in.
The Matrix Diagrammer allows you to select any two elements, such as functions and entities, and display the intersections of these elements in a two-dimensional grid. You can scroll through this matrix and see how the elements intersect. You can select the specific information you want to display for each intersection--for example, you might want to display a function's CRUD usage of an entity. You can also display the intersection of elements using iconic mode, which simply shows a check mark at each intersection.
Once you've created your Function to Entity matrix, you can add details through individual data entry screens or by pointing and clicking on an intersection and adding information to the dialog box that appears. Details commonly added during the strategy and analysis stages of Oracle's CASE*Method include CRUD information; frequency, or how many times the function will be performed in a period of time; and volume, including the minimum, maximum, and average number of occurrences of an entity. Designer/2000 will later use this information to help you determine system sizing, which you can then use to determine your hardware requirements.
Once you've created and examined various matrix models in the Matrix Diagrammer, how do you know when you're finished? Even more important, how do you know when you're ready to begin translating your logical model into a physical model? In Oracle's CASE* Method, you develop and complete the logical model during the strategy and analysis stages. These two stages mark the boundaries for deciding the scope of the implementation--what will become code and what won't. After you've made that determination, you make the logical to physical translation in the design stage.
Gathering, evaluating, modeling, and gaining agreement with your users during the strategy and analysis stages is an on-going, dynamic process that requires good detective work--asking the right questions of the appropriate people in such a way that you'll get the answers you need to create an agreed-upon model. Using top-down and bottom-up modeling approaches, as we discussed in our article on function hierarchy modeling, you can set the direction of the project and explore specific business in more detail.
The task of determining whether you're finished with the logical model is a joint effort between you and your users. In many cases, there will be parts of the application that look too expensive or time-consuming to pursue at this time. Perhaps these parts could be scaled down or saved for a subsequent phase. For a successful implementation, all parties must agree that the scope of the application will satisfy the business needs of your organization. And they need to understand that any changes from now on to this scope will impact the project deadline and cost more money.
We're now ready to begin our discussion of the physical aspects of application development using the information we've recorded in Designer/2000. In next month's article, we'll begin the transformation from logical to physical models using the Database Design Wizard.
If you'd like to find out more about Oracle's approach to matrix modeling, please read CASE*Method - Function and Process Modelling by Richard Barker and Cliff Longman (Oracle/Addison-Wesley, 1992). You'll find Chapter 8 to be of specific help. For CASE quality assurance in general, we also recommend CASE*Method - Tasks and Deliverables by Richard Barker (Oracle/Addison-Wesley, 1990).
David Moss is a managing consultant with TrueNorth Consulting,
Inc. David has been an active user of Oracle's CASE tools and
methodology since 1988, including over three years with Oracle
Consulting Group. You can reach him by phone at (503) 220-1790
or by E-mail at truenrth@ix.netcom.com.
[Return to Index for Exploring Oracle Developer/2000 and Designer/2000 - May 1996]
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.
1-800-223-8720
(Sun Microsystems, Inc.)(1997).iso/products/Cobb/ord9605/eod9651a.gif){kind=link}